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ABSTRACT 


As  part  of  the  transition  from  the  current  paper-intensive  processes  to  a highly 
automated  and  integrated  mode  of  operation,  the  Navy  is  adopting  the  Initial  Graphics 
Exchange  Specification  (IGES)  for  certain  digital  data  exchanges  among  elements  of 
the  Navy  and  Navy  contractors.  This  report  provides  strategies  and  recommendations 
for  implementing  IGES  for  exchanging  and  archiving  digital  representations  of  Naval 
Facilities  Engineering  Command  (NAVE AC)  projects. 

NAVF AC  plans  to  benefit  from  the  use  of  computer-aided  design  and  drafting 
(CADD)  by  encouraging  outside  architecture,  engineering,  and  construction  (AEC) 
firms  to  acquire  CADD  capabilities  and  by  requiring  the  delivery  of  certain  project 
documentation  in  digital  form.  The  ability  to  transmit  drawings  and  specifications  be- 
tween different  CADD  systems  is  expected  to  reduce  the  time  (and  resources)  that 
NAVE  AC  and  outside  personnel  spend  reviewing,  changing,  and  managing  projects 
and  also  to  improve  the  quality  of  the  projects. 

In  order  to  effectively  integrate  CADD  technology  and  contract  with  the  AEC  industry, 
NAVE  AC  requires  a comprehensive  and  reliable  data  exchange  mechanism.  This  will 
require  thorough  technical  information  management,  long-term  planning  for  the  trans- 
fer and  archiving  of  digital  data,  and  the  allocation  of  resources  for  the  execution  of  the 
recommendations  of  this  report. 

Key  words:  AEC  CADD;  CADD  data  exchanges;  computer-aided  design  and  draft- 

ing; data  exchange  standards;  data  translators;  IGES;  information 
management;  NAVE  AC;  translation  quality  assurance;  validation  of 
data  translators 
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1.  Introduction 


The  Naval  Facilities  Engineering  Command  (NAVFAC)  faces  critical  technical  chal- 
lenges in  optimizing  its  use  of  computer-aided  design  and  drafting  (CADD)  and  in- 
tegrated information  systems.  During  the  past  three  years,  NAVFAC  has  made  major 
commitments  to  the  use  of  CADD  for  the  planning,  design,  and  operation  of  Naval 
Shore  Facilities.  Traditional  paper-intensive  engineering,  design,  and  drafting  proces- 
ses are  quickly  evolving  to  computer-based  technologies. 

As  NAVFAC  and  the  Architecture,  Engineering,  and  Construction  (AEC)  industry  ex- 
pand their  use  of  CADD,  the  communication  of  project  information  among  participat- 
ing professionals  becomes  increasingly  complex.  This  situation  requires  comprehen- 
sive technical  information  management,  long-term  planning  for  the  transfer  and  archiv- 
ing of  digital  data,  and  the  immediate  allocation  of  resources  for  the  recommendations 
of  this  report. 

NAVFAC  plans  to  benefit  from  the  use  of  CADD  by  encouraging  outside  architecture 
and  engineering  (A/E)  firms  to  acquire  CADD  capabilities  and  by  requiring  the 
delivery  of  project  documentation  in  digital  form.  The  ability  to  transmit  drawings  and 
specifications  between  different  CADD  systems  is  expected  to  reduce  the  time  (and 
resources)  that  A/E  and  NAVFAC  personnel  spend  reviewing,  changing,  and  manag- 
ing projects  and  also  to  improve  the  quality  of  the  projects.  Additionally,  with  the 
design  and  as-built  information  stored  in  a digital  database,  the  planning,  operation, 
maintenance,  and  renovation  of  Naval  facilities  will  be  greatly  enhanced. 

However,  for  NAVFAC  to  succeed  with  these  goals,  data  exchange  capabilities  be- 
tween multiple,  dissimilar  CADD  systems  must  be  achieved.  There  are  over  80  dif- 
ferent CADD  systems  currently  being  used  for  AEC  operations,  and  no  one  CADD 
system  has  yet  fulfilled  all  of  the  requirements  for  every  type  of  firm.  The  AEC  industry 
has  committed  itself  to  working  in  a heterogeneous  CADD  environment.  In  order  to 
effectively  integrate  CADD  and  contract  with  the  AEC  industry,  NAVFAC  requires  a 
comprehensive  and  dependable  data  exchange  mechanism. 

The  Navy  is  working  in  concurrence  with  the  DoD  goal  of  increased  capability  to 
receive,  distribute,  and  use  technical  information  in  digital  form.  The  DoD  Computer- 
Aided  Acquisition  and  Logistic  Support  (CALS)  Program  is  currently  defining  the 
DoD-wide  required  use  of  the  Initial  Graphics  Exchange  Specification  (IGES)  for  the 
delivery  of  digital  data  (proposed  standardization  document,  MIL-D-28000). 

As  part  of  its  transition  from  the  "current  paper-intensive  logistic  processes  to  a high- 
ly automated  and  integrated  mode  of  operation"  [1],  the  Navy  is  adopting  IGES  for  cer- 
tain data  exchanges  among  elements  of  the  Navy  and  Navy  contractors.  A key  step  in 
this  transition  has  been  the  Navy’s  decision  for  mandatory  compliance  with  IGES  (cur- 
rent and  future  versions)  in  their  future  purchases  of  CADD  systems. 
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Naval  Sea  Systems  Command  (NAVSEA)  has  already  established  a Digital  Data  Trans- 
fer Program  for  its  new  class  of  submarines  (Seawolf  SSN21),  and  this  program  relies 
heavily  upon  the  use  of  IGES.  The  Seawolf  Digital  Data  Program  has  clearly  illustrated 
that  the  successful  use  of  IGES  by  Navy  commands  will  require  broad  commitments  by 
all  participants  and  significant  investments  in  translator  testing  and  translation  quality 
assurance  procedures. 

This  report  presents  strategies  and  recommendations  for  NAVFAC’s  implementation 
of  IGES  for  exchanging  and  archiving  digital  representations  of  AEC  projects.  The 
goal  of  these  efforts  is  to  ensure  that  NAVE  AC  will  have  a dependable  means  of  ex- 
changing AEC  CADD  information. 


1.1  Definitions 

The  following  definitions  are  presented  to  clarify  the  terminology  of  this  report. 

CADD  - Computer-Aided  Design  and  Drafting.  The  use  of  a computer  system  for 
design  and  drafting  operations. 

CADD  Model  - The  representation  of  the  information  that  is  used  to  describe  a project, 
in  the  format  of  the  CADD  system. 

Data  - A representation  of  facts,  concepts,  or  instructions  in  a formalized  manner 
suitable  for  communication,  interpretation,  or  processing  by  human  or  automatic  (i.e., 
in  computer-readable  form)  means.  [2] 

Data  Exchange  Standard  - Describes  the  format  and  content  of  the  data  to  be  digi- 
tally exchanged  between  different  CADD  systems. 

IGES  - Initial  Graphics  Exchange  Specification,  a data  exchange  standard  (refer  to 
Section  3.1).  [3] 

IGES  Model  - The  representation  of  project  definition  data  in  IGES  format.  This  is 
usually  in  the  form  of  a library  of  IGES  files. 

Information  Model  - Defines  the  structure  and  the  semantics  of  the  information  that 
is  required  for  the  tasks  of  the  specified  applications,  such  as  a NAVF AC  AEC  project 
information  model  for  the  design,  construction,  and  operation  of  Naval  Shore  Facilities. 

Processable  Data  - Structured  information  partitioned  into  distinct  data  elements 
(fields)  that  can  be  transmitted  and  manipulated  by  electronic  means  between  various 
activities  engaged  in  the  design,  construction,  and  operation  of  Naval  facilities.  [4] 
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Project  Data  - All  types  of  data  that  apply  to  the  project  life  cycle,  including  project 
definition  data,  engineering  calculations,  project  and  facility  management  data,  finan- 
cial data,  quality  assurance  data,  and  testing  results.  This  is  not  an  exhaustive  list. 

Project  Definition  Data  - A subset  of  project  data  that  includes  only  those  data  ele- 
ments necessary  for  the  planning,  analysis,  design,  and  construction  of  a project. 

Technical  Information  - Encompasses  technical  documents,  engineering  information 
(drawings,  calculations,  and  specifications),  and  the  meanings  (information)  that  can 
be  inferred  from  project  data. 
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2.  Analysis  of  the  Information  Requirements  of  NAVFAC 

A key  element  for  improved  productivity  and  the  integration  of  CADD  is  the  effective 
management  of  technical  information.  The  lack  of  a unified  approach  to  information 
and  digital  data  management  can  result  in  inefficient  storage  and  significant  potential 
for  errors  due  to  data  redundancy.  The  point  that  must  be  made  is  that  the  under- 
standing of  NAVFAC’s  data  exchange  requirements  is  based  upon  a thorough  analysis 
of  the  information  flow  and  data  requirements  of  the  organization. 

The  successful  use  of  IGES  will  require  this  comprehensive  view  of  the  information 
flow  of  NAVFAC’s  AEC  operations  and  the  development  of  a systematic  implemen- 
tation plan.  This  should  include  documenting  what  information  is  needed  for  every 
task  and  developing  a specification  and  schedule  for  how  that  information,  in  various 
forms,  will  be  delivered,  managed,  and  archived. 

In  order  to  develop  a long-term  strategic  plan  for  technical  information  management, 
it  is  essential  to  understand  what  information  NAVFAC  uses  and  how  NAVFAC’s  sys- 
tems will  process  that  information.  Central  to  this  long-term  plan  will  be  the  develop- 
ment of  a NAVFAC  information  model.  An  information  model  defines  the  structure 
and  the  semantics  of  the  information  that  is  required  for  the  tasks  of  the  specified  ap- 
plications, i.e.,  a NAVFAC  AEC  project  information  model  for  the  design,  construc- 
tion, and  operation  of  Naval  Shore  Facilities. 

The  project  information  model  will  be  used  to  specify  the  CADD  data  modeling  con- 
ventions and  the  required  data  translation  conventions.  With  a documented  NAVFAC 
AEC  project  information  model  as  a road-map,  appropriate  structuring  or  mapping  to 
future  CADD  systems’  data  structures  and  future  data  exchange  standards  will  require 
significantly  shorter  completion  schedules. 

The  central  issues  are  what  information  is  required  to  accomplish  each  NAVFAC  AEC 
project  function  and  how  that  information  should  be  transferred  and  managed.  Since 
the  engineering  drawing  will  continue  to  be  a key  construction  document,  this  analysis 
must  identify  the  relationships  between  computerized  and  manually  processed  infor- 
mation, organizational  accountability,  and  quality  assurance  procedures. 

Initially  this  analysis  will  define  what  information  is  required  to  transfer  a set  of  produc- 
tion documents,  i.e.,  "engineering  release  documents".  The  next  step  is  to  specify  which 
of  this  information  is  appropriate  to  transfer  and  archive  using  the  Navy’s  current  data 
exchange  standards.  (During  the  short-  and  mid-term,  one  of  these  data  exchange 
standards  will  be  the  current  version  of  IGES.)  This  "technical  information  manage- 
ment and  transfer  specification"  will  define  NAVFAC’s  required  use  of  IGES  and  will 
coordinate  the  use  of  digital  data  with  the  other  forms  of  required  information. 
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2.1  Overview  of  NAVFAC  Operations  and  AEC  Applications 


NAVFAC  is  in  charge  of  the  planning,  design,  construction,  operation,  and  renovation 
of  Naval  Shore  Facilities.  With  an  annual  construction  budget  of  approximately  $1.8 
billion  [5],  NAVFAC  is  one  of  the  largest  engineering  and  construction  organizations 
in  the  world.  More  than  85%  of  this  mapping,  design,  and  construction  work  is  done 
by  outside  firms,  and  NAVFAC  will  often  work  with  more  than  1,500  different  firms 
annually. 

The  NAVFAC  process  starts  with  survey  data  for  the  Facilities  Geographic  Informa- 
tion System,  and  this  mapping  information,  often  in  the  form  of  a digital  terrain  model, 
provides  the  basis  for  all  subsequent  AEC  project  information.  Since  NAVFAC  is 
responsible  for  the  entire  life  cycle  of  all  Naval  Shore  Facilities,  most  AEC  project  in- 
formation will  be  essential  for  at  least  twenty-five  years  and  possibly  far  longer.  This 
will  require  the  long-term  archiving  of  digital  project  databases,  in  a neutral  format,  so 
that  they  may  be  effectively  used  in  the  future  on  different  CADD  systems. 

NAVFAC  has  made  major  commitments  to  the  use  of  automation  in  the  planning  and 
design  of  facilities.  Currently  there  are  minicomputer  CADD  systems  (Computer- 
vision,  CADDS®  4X1)  installed  at  multiple  locations  across  the  country:  NAVFAC 
Headquarters,  6 Engineering  Field  Divisions  (EFDs),  5 Public  Works  Centers  (PWCs), 
the  Naval  Civil  Engineering  Laboratory,  and  the  Civil  Engineering  Office.  The  goals 
of  this  investment  are: 

• to  reduce  the  time  A/E  and  NAVFAC  personnel  spend  reviewing/changing 
designs  and  specifications; 

• to  improve  the  contract  document  process; 

• to  improve  the  quality  of  the  projects; 

• to  move  from  paper-based  operations  to  3-D  digital  model-based  operations, 
and 

• to  enhance  facility  life-cycle  operations  with  the  coordinated  use  of  CADD 
databases. 


1 Certain  commercial  equipment,  software,  or  materials  are  identified  in  this 
report  in  order  to  adequately  specify  existing  CADD  software  and  data 
exchange  formats.  Such  identification  does  not  imply  endorsement  by  the 
National  Bureau  of  Standards,  nor  does  it  imply  that  the  software  or  equipment 
are  necessarily  the  best  available  for  the  purpose. 
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NAVFAC’s  operations,  which  have  been  the  traditional  paper-based  processes  (refer 
to  Figure  2-1),  are  quickly  evolving  to  computer-based  technologies  (refer  to  Figure  2- 
2).  The  Department  of  Navy  is  now  in  the  Request  for  Proposal  (RFP)  process  for  the 
second  Navy  CAD/CAM  (Computer-Aided  Design  / Manufacturing)  Acquisition.  The 
selected  systems  will  be  used  for  a broad  range  of  CAD/CAM  applications  in  the  Navy. 
The  RFP  includes  the  mandatory  compliance  to  the  current  version  and  all  future  ver- 
sions of  IGES. 

Due  to  continuing  advances  in  CADD  technology  and  the  federal  requirements  for 
competitive  bidding,  there  is  no  guarantee  that  NAVFAC’s  second  CADD  acquisition 
will  be  the  same  kind  of  system  as  is  currently  installed.  In  order  to  successfully  in- 
tegrate the  Navy’s  phased  acquisition  of  CADD  workstations  and  to  effectively  con- 
tract with  multiple  outside  ABC  firms,  NAVFAC  requires  a dependable  means  of 
moving  CADD  information  between  incompatible  systems. 


Traditional  Building  Project  Information  Transfer: 


DwgsSpec 
Sub- Sets 


A Paper  Chase 


Figure  2-1  Traditional,  Paper-Based  Project  Information  Transfer  Process 
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Figure  2-2  Computer-Based  Approach  to  Project  Information  Transfer  Process  [6] 
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2.2  NAVFAC  Requirements  for  the  Delivery  of  Digital  Data 


NAVFAC  has  already  taken  major  steps  in  moving  its  paper-based  design/drafting 
processes  toward  computer-based  operations.  A primary  objective  of  this  transition  is 
to  be  able  to  generate  all  drawings  from  3-D  project  models.  Procedures  have  been  es- 
tablished for  the  classification  and  control  of  CADD  drawings  and  for  creating  CADD 
models  of  AEC  projects.  The  long-term  goal  is  to  use  databases  of  digital  project  models 
for  comprehensive  life-cycle  facilities  engineering  (mapping,  planning,  design,  opera- 
tion, management,  and  reuse). 

NAVFAC  has  developed  a standard  scope  of  work  for  the  delivery  of  AEC  project  in- 
formation/documentation in  digital  form.  This  specification  provides  a structure  for 
coordinating  the  delivery  of  digital  data  and  defines  NAVFAC’s  requirements  with 
respect  to: 

• File  naming  conventions  (drawings  and  3-D  model) 

• Layering  conventions 

• Non-graphic  properties 

• Standard  symbols/details 

• Part  structuring 

• Design/drafting  process 


"The  A/E  shall  deliver  as  a minimum,  part  data  bases,  definitive  design  modules  as 
directed  by  the  OIC  (Officer-in-Charge),  drawing  parts,  figure  files  and  their  parent 
parts,  line  and  text  font  definition  files,  pattern-hatch  files,  non-graphic  property  files, 
extract  data  definition  files,  computer  programs  with  source  codes,  and  plotting  instruc- 
tions developed  as  part  of  the  contract.  Data  base  documentation  and  operational 
manuals  shall  be  delivered.  Design  part  data  bases  and  other  files  shall  be  delivered 
on  9-track,  1600  bpi  standard  1/2  inch  magnetic  tapes  readable  by  Computervision  (CV) 
software.  Both  IGES  and  CAPPS  4X  data  bases  are  required.  The  IGES  data  base 
file(s)  must  contain  complete  and  comparable  data  as  in  CAPPS  4X. 

(Note:  Non-graphic  property  files  and  extract  data  definition  files  are  not  required 
since  IGES  does  not  support  them  yet.)"  [7] 

The  reasons  for  requiring  IGES  files  are  as  follows: 

• to  give  IGES  library  parts  to  the  A/E  to  reduce  A/E  cost; 

• to  give  IGES  standard  designs  to  the  A/Es  for  site  adaptation  to  reduce  A/E 
cost; 

• to  give  IGES  facility  databases  to  the  A/E  for  rehab  work,  and 


8 


• to  give  IGES  facility  databases  to  PWCs  (Public  Works  Centers)  with  non- 
CV  systems  for  operation,  maintenance,  and  rehab  work. 

2.3  The  Importance  of  Standards  for  CADD  Operations 

In  order  to  ensure  the  quality  and  the  consistency  of  CADD  information  and  to  effec- 
tively share  this  information  among  project  participants,  it  is  necessary  to  establish  com- 
prehensive standards  for  CADD  operations.  These  standards  should  be  developed  as 
part  of  a comprehensive  information  management  plan  and  should  define  uniform 
CADD  modeling  conventions,  drawing  file  setups,  layering  assignments,  and  stand- 
ardized facilities  databases.  Standardization  of  procedures  and  practices  helps  to  more 
fully  utilize  personnel  skills  and  reduces  the  training  costs  incurred  by  the  continual 
turnover  in  staffing. 

The  Department  of  the  Navy  and  NAVFAC  have  already  established  engineering 
drawing  standards  and  symbol  standards.  These  standards  need  to  be  revised  to  reflect 
CADD-based  operations.  It  is  important  to  understand  that  the  introduction  of  com- 
puter graphics  and  CADD  based  operations  is  having  major  effects  on  the  way  the  work 
will  be  done.  Standards  must  be  established  for  conducting  business  when  using  digi- 
tal project  definition  data,  with  the  intention  of  controlling  the  use,  development,  ex- 
change, and  maintenance' of  CADD  databases. 

A key  requirement  for  NAVFAC’s  CADD  standards  is  the  development  of  the  NAV- 
FAC AEC  project  information  model.  The  information  model  defines  the  structure 
and  semantics  of  the  information  that  is  required  to  accomplish  NAVFAC’s  tasks  in 
the  planning,  design,  construction,  and  operation  of  Naval  Shore  Facilities.  This  model 
provides  a stable  foundation  and  reference  for  specifying  and  managing  how  each  type 
of  technical  information  will  be  exchanged  and  archived. 

A critical  information  management  issue  within  NAVFAC’s  transition  to  CADD-based 
operations,  is  the  use  of  CADD  databases  as  the  sole  authority  for  AEC  project  infor- 
mation. In  most  of  the  manufacturing  organizations  that  have  moved  to  CADD-based 
operations,  the  CADD  files  and  the  conventional  drawings  currently  have  dual 
authority.  Until  NAVFAC  and  its  AEC  contractors  are  prepared  to  make  the  CADD 
database  the  sole  authority,  there  will  be  significant  requirements  for  duplicate  infor- 
mation, configuration  management,  and  project  model/drawings  control  procedures. 

As  the  IGES  specification  and  the  quality  of  the  IGES  translators  improve,  it  will  be 
possible  to  exchange  more  of  this  information  via  IGES.  Yet,  in  order  to  chart  and 
maintain  control  of  NAVFAC’s  migration  to  CADD-based  operations,  this  informa- 
tion model  will  be  required.  During  the  short-term,  NAVFAC  should  develop  their 
specification  for  IGES  deliverables  and  a schedule  for  phases  of  development,  testing, 
implementation,  and  revision  of  the  specification. 
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3.  The  Use  of  IGES  for  Exchanging  Drawings  and  AEC  Project 
Definition  Data 

Central  to  the  successful  integration  of  CADD  is  the  development  of  dependable  data 
exchange  methods.  Most  CADD  systems  are  incompatible  because  each  uses  its  own 
concepts,  terminology,  and  encoding  schemes  (different  representation  formats)  for 
storing  information.  This  limits  or  prevents  the  flow  of  CADD  information  between 
different  systems  and  the  various  project  participants. 

There  are  basically  two  ways  to  transfer  data  between  incompatible  CADD  systems: 
direct  translation  and  translation  via  a neutral  format.  A direct  translator  is  a software 
program  which  converts  data  sets  from  their  original  format  into  the  specific  format 
of  a receiving  system. 

Although  direct  translators  can  be  an  efficient  way  to  exchange  data  between  two 
CADD  systems,  they  do  not  provide  a viable  mechanism  for  exchanging  data  between 
multiple  dissimilar  systems.  The  writing  of  direct  translators  requires  a complete  un- 
derstanding of  the  internal  data  format  used  by  both  the  sending  and  the  receiving  sys- 
tem. Since  this  information  is  subject  to  periodic  revisions  and  is  usually  proprietary, 
the  use  of  direct  translators  imposes  large  software  support  problems. 

The  use  of  neutral  translators  is  intended  to  resolve  these  limitations.  A neutral  trans- 
lator is  based  on  the  concept  of  an  intermediate  (neutral)  format  and  utilizes  two 
programs  (a  preprocessor  and  a postprocessor)  to  perform  the  translation.  The 
preprocessor  reads  the  format  of  system  A and  writes  into  the  neutral  format,  and  the 
postprocessor  reads  the  neutral  format  and  writes  the  output  into  the  format  of  system 
B. 

There  are  several  advantages  to  this  process.  First,  the  writing  of  either  program  only 
requires  an  understanding  of  the  internal  (proprietary)  data  format  of  one  system  and 
the  neutral  format.  Second,  fewer  programs  are  required  (for  "n"  CADD  systems,  only 
2n  one-way  neutral  translators  are  needed,  versus  nxfn-11  one-way  direct  translators). 
For  example,  among  10  systems,  there  needs  to  be  only  10x2  = 2Q  one-way  neutral 
translators,  versus  10x9  = 90  one-way  direct  translators.  Additionally,  the  use  of  an  in- 
termediate format  can  reduce  the  users’  risks  of  vendor  dependence  and  can  allow 
greater  flexibility  in  the  utilization  of  CADD  resources. 

In  order  to  resolve  its  CADD  data  exchange  requirements,  the  Navy  has  selected  IGES 
as  an  intermediate  (system  independent)  data  exchange  standard.  IGES  is  an  interna- 
tional consensus  standard  for  the  exchange  of  project/product  definition  data.  This 
standard  grew  out  of  the  work  done  by  the  Boeing  Corp.,  the  General  Electric  Corp., 
the  NASA/Navy  sponsored  Integrated  Program  for  Aerospace  Vehicle  Design  (IPAD), 
and  the  U.S.  Air  Force  Integrated  Computer-Aided  Manufacturing  (ICAM)  program. 
Each  of  these  organizations  had  identified  the  lack  of  a standard  for  the  exchange  of 
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CADD  graphics  as  a critical  obstacle  to  moving  toward  computer  integrated  operations 
(specifically  CAD/CAM  operations).  The  IGES/PDES  (Product  Data  Exchange 
Specification)  Organization  coordinates  the  ongoing  efforts  to  enhance  future  versions 
ofIGES. 

Unfortunately,  the  intelligence  and  complexity  of  AEC  project  definition  data  (as  rep- 
resented in  conventional  project  documentation  and  drawings)  exceeds  that  of  a typi- 
cal mechanical  part  drawing.  Partially  due  to  this  factor,  the  current  generation  ofIGES 
translators  (which  were  primarily  designed  for  CAD/CAM  processes)  is  inadequate  for 
comprehensive  AEC  CADD  operations.  Incomplete  translators,  insufficient 
documentation,  and  differing  interpretations  of  specifications  have  prevented  accurate 
and  consistent  AEC  digital  data  exchanges.  [8] 

The  current  version  of  IGES  (Version  3.0)  can  support  most  of  the  graphics  of  a typi- 
cal AEC  drawing,  and  CADD  vendors  are  improving  the  capabilities  of  their  IGES 
translators.  Future  versions  ofIGES  will  provide  more  efficient  mechanisms  to  include 
all  of  the  graphics  and  some  of  the  non-geometric  information  of  typical  AEC  draw- 
ings. It  is  important  to  understand  that  the  graphics  of  typical  drawings  are  only  part 
of  the  information  that  is  required  for  the  comprehensive  use  of  CADD  for  the  plan- 
ning, design,  and  operation  of  Naval  Shore  Facilities. 


3.1  A Description  of  IGES 

The  Initial  Graphics  Exchange  Specification  (IGES)  was  designed  to  accommodate  the 
exchange  of  product  definition  data  between  CADD  systems.  The  IGES  standard 
defines  a file  structure  format,  a language  format,  and  the  representation  of  geometric, 
topological,  and  non-geometric  data  in  these  formats.  The  specification  subdivides 
product  definition  data  into  three  categories:  geometry  entities,  annotation  entities, 
and  structure  entities.  The  basic  element  of  data  in  an  IGES  file  is  an  entity. 

In  IGES  Version  3.0  there  are  54  defined  entity  types,  each  with  a unique  entity  type 
number.  Some  entity  types  are  further  subdivided  by  form  numbers.  Additionally,  the 
specification  provides  entity  type  numbers  for  user-defined  entities. 
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3.1.1  Geometry  Entities 


Geometry  entities  define  the  geometry  of  the  product/project  description  (e.g.,  points, 
lines,  arcs,  and  ruled  surfaces),  as  shown  in  Table  3-1. 


Entity  Tvoe  Entity  Tvoe  Number 

Circular  Arc 

100 

Composite  Curve 

102 

Conic  Arc 

104 

Copious  Data 

106 

Plane 

108 

Line 

110 

Parametric  Spline  Curve 

112 

Parametric  Spline  Surface 

114 

Point 

116 

Ruled  Surface 

118 

Surface  of  Revolution 

120 

Tabulated  Cylinder 

122 

Transformation  Matrix 

124 

Flash 

125 

Rational  B-Spline  Curve 

126 

Rational  B-Spline  Surface 

128 

Offset  Curve 

130 

Connect  Point 

132 

Node 

134 

Finite  Element 

136 

Nodal  Displacement  and  Rotation 

138 

Offset  Surface 

140 

Curve  on  a Parametric  Surface 

142 

Trimmed  Parametric  Surface 

144 

Table  3-1  IGES  3.0  Geometry  Entities 


3.1.2  Annotation  Entities 


Annotation  entities  define  the  notes  that  are  added  to  the  description  of  the 
product/project,  as  shown  in  Table  3-2.  In  the  case  of  engineering  drawings,  these  in- 
clude linear  and  angular  dimensions,  text,  and  tolerance  information. 


Entity  Type 

Angular  Dimension 
Diameter  Dimension 
Flag  Note 
General  Label 
General  Note 
Leader  (Arrow) 
Linear  Dimension 
Ordinate  Dimension 
Point  Dimension 
Radius  Dimension 
General  Symbol 
Sectioned  Area 


Entity  Type  Number 

202 

206 

208 

210 

212 

214 

216 

218 

220 

222 

228 

230 


Table  3-2  IGES  3.0  Annotation  Entities 


3.13  Structure  Entities 

Structure  entities  define  various  logical  relationships  within  the  product/project  defini- 
tion data.  They  are  used  to  communicate  the  structure  of  the  CADD  data  and  database. 
This  includes  describing  subfigures  (symbols),  associativities,  views  of  the  project 
model,  and  drawings,  as  shown  in  Table  3-3.  The  intent  of  the  view  entity  and  the  draw- 
ing entity  is  to  allow  the  use  of  two  dimensional  representations,  while  maintaining  a 
single  model  description.  The  drawing  entity  also  provides  a place  to  collect  the  an- 
notation entities  that  are  used  to  clarify  the  selected  view  of  the  model. 
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Entity  Type 


Entity  Type  Number 


Associativity  Definition 

302 

Line  Font  Definition 

304 

MACRO  Definition 

306 

Subfigure  Definition 

308 

Text  Font  Definition 

310 

Text  Display  Template 

312 

Color  Definition 

314 

Network  Subfigure  Definition 

320 

Associativity  Instance 

402 

Drawing  Entity 

404 

Property  Entity 

406 

Singular  Subfigure  Instance 

408 

View  Entity 

410 

Rectangular  Array  Subfigure  Instance 

412 

Circular  Array  Subfigure  Instance 

414 

External  Reference 

416 

Nodal  Load/Constraint 

418 

Network  Subfigure  Instance 

420 

MACRO  Instance  (user  defined) 

600-699  or 

10000-99999 

Table  3-3  IGES  3.0  Structure  Entities 


3.1.4  IGES  File  Structure 

The  IGES  file  structure  is  divided  into  five  sections:  Start,  Global,  Directory,  Parameter 
Data,  and  Terminate  sections.  An  IGES  entity  has  at  least  two  parts,  first  a directory 
entry  and  then  a parameter  data  entry.  Within  each  section,  each  entry  occupies  con- 
tiguous records. 

An  IGES  file  is  written  in  80  column  records,  using  the  ASCII  character  set.  Each 
record  has  a letter  in  column  73  , which  identifies  the  section  (S  for  Start,  D for  Direc- 
tory, etc.)  and  a right  justified  number  in  columns  74  through  80  for  the  position  of  the 
record  in  that  section. 

The  Start  Section  provides  the  human  interpretable  prologue  to  the  file.  This  section 
is  used  for  any  text  that  will  label  the  file  and  explain  its  contents.  Each  IGES  file  must 
have  at  least  one  Start  record.  The  Global  Section  describes  the  preprocessor  and  other 
information  that  the  postprocessor  may  need  to  translate  the  IGES  file.  The  Directory 
Entry  Section  has  one  entry,  consisting  of  two  records,  for  each  entity  in  the  IGES  file. 
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The  Parameter  Data  Section  contains  the  parameter  data  for  the  entities  in  the  Direc- 
tory Entry  Section  and  is  usually  the  largest  section  in  the  file.  Every  IGES  file  has  one 
record  in  the  Terminate  Section,  and  it  lists  the  total  number  of  records  in  each  one  of 
the  sections. 


3.2  Key  Issues  Concerning  the  Use  of  IGES 

For  an  intermediate  data  format  to  be  completely  successful,  it  must  be  sufficiently 
powerful  to  express  all  types  of  information  in  any  originating  system,  without  the 
receiver  having  to  know  the  original  (internal)  data  structure.  No  intermediate  format 
has  yet  been  fully  successful  in  supporting  the  data  exchange  requirements  of  all  AEC 
CADD  users. 

The  early  versions  of  IGES  (Ver.  1.0  and  2.0)  were  inadequate  for  the  data  exchange 
requirements  of  the  AEC  industry,  produced  excessively  large  files,  and  did  not  address 
the  archival  requirements.  Although  IGES  is  intended  to  serve  as  an  archival  format, 
the  primary  focus  of  the  IGES  effort  has  been  on  successful  system  to  system  com- 
munication using  IGES  translator  implementations. 

Initially,  many  of  the  vendors  only  implemented  a small  percentage  of  the  specification 
(although  they  would  advertise  IGES  capabilities)  and  did  not  provide  adequate 
documentation  or  software  tools  for  diagnosing  translation  problems.  Most  IGES 
translators  use  only  a subset  of  the  specification,  do  not  have  comprehensive  error 
recovery  capabilities,  and  do  not  provide  diagnostic  transaction  reporting.  These 
limitations  have  frustrated  many  AEC  CADD  users. 

A key  AEC  example  of  this  situation  is  the  limited  implementation  of  the  subfigure  en- 
tity in  many  vendor-provided  IGES  translators.  Each  element  of  data  in  an  IGES  file 
is  an  entity,  and  the  subfigure  entity  is  a collection  of  entities  which  can  be  used  in  mul- 
tiple instances. 

AEC  project  definitions  contain  a large  number  of  repetitive  elements  which  results  in 
frequent  instancing  of  the  same  symbol  (i.e.,  subfigure  entity).  The  use  of  the  subfigure 
entity  provides  a way  to  retain  the  intelligence  of  the  symbols,  replicates  what  A/Es  do 
in  practice,  and  reduces  the  IGES  file  size.  This  is  a crucial  issue  for  construction  in- 
dustry firms  that  need  to  exchange  detailed  drawings,  and  yet  many  vendor-provided 
IGES  translators  still  do  not  support  the  subfigure  entity. 

During  the  past  five  years  (since  becoming  an  ANSI  standard),  IGES  has  been  ex- 
panded to  provide  more  sophisticated  capabilities  and  to  support  more  applications. 
One  consequence  of  trying  to  make  IGES  be  all  things  to  all  users  has  been  the  in- 
clusion of  multiple  ways  to  encode  the  same  data.  Some  of  the  enhancements  to  IGES 
have  added  to  its  complexity  and  ambiguity,  and  this  has  increased  the  difficulty  of  using 
IGES  effectively. 
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The  quality  of  IGES  translators  has  significantly  improved  during  1987,  and  the  Ver- 
sion 3.0  document  has  resolved  some  of  the  earlier  problems  in  the  specification.  IGES 
Version  3.0  provides  for  enhanced  user  defined  MACRO’S  so  as  to  better  represent 
standard  part  libraries  and  defines  a new  extension  for  External  Reference  Files  (e.g., 
to  reference  libraries  of  standard  symbols). 


3.2.1  Flexibility  and  Limitations  of  IGES 

A primary  limitation  on  the  current  use  of  IGES  is  the  ambiguity  and  the  flexibility  of 
the  current  IGES  standard.  There  are  multiple  ways  of  representing  the  same  techni- 
cal information  in  IGES  format  (e.g.,  multi-segment  lines,  dimensions,  and  properties 
information)  and  multiple  ways  to  process  an  IGES  file.  Since  the  vendors  have  not 
interpreted  the  specification  uniformly,  there  are  incompatibilities  in  the  mappings  be- 
tween the  preprocessor  of  one  vendor  and  the  postprocessor  of  a different  vendor. 

To  date,  those  organizations  that  have  successfully  exchanged  information  using  IGES 
(Boeing  Aerospace,  General  Motors,  Hughes  Aircraft,  NAVSEA,  and  Pratt  and  Whit- 
ney) have  had  to  make  major  investments  of  time  and  money  to  test  IGES  transfers 
and  to  develop  their  particular  IGES  specifications  and  procedures. 

Until  recently,  there  had  only  been  limited  testing  and  validation  of  the  accuracy  and 
usefulness  of  IGES  translators.  The  implementation  of  IGES  must  include  the 
development  of  standard  conformance  tests  for  IGES  software  tools  and  for  the 
delivery  of  data  in  IGES  format.  In  order  to  effectively  exploit  both  the  capabilities  of 
CADD  and  the  benefits  of  implementing  IGES,  NAVF AC  and  the  AEC  industry  will 
require  consistent  and  reliable  IGES  translators  and  uniform  procedures  for  encoding 
project  definition  data  into  IGES  format. 


3.2.2  Mismatch  of  Systems’  Capabilities  and  Entities 

The  exchange  of  information  between  dissimilar  AEC  CADD  systems  (i.e.,  within 
heterogeneous  environments)  involves  several  potential  problem  areas.  With  just 
drafting  systems,  these  problems  include  differences  in  functionality  and  terminology, 
such  as  levels  vs.  layers,  entity  mismatches,  conflicting  drawing  sizes  and  scales,  and  in- 
compatible line  styles  and  text  fonts.  The  data  translation  problems  can  become  far 
more  complex  when  exchanging  information  between  3-D  modeling  and  engineering 
software  systems. 

The  principal  cause  for  these  problems  is  differences  in  the  logical  structure  of  the 
CADD  systems  (such  as  subfigure  and  connectivity  definitions).  Most  early  CADD 
systems  were  computerized  drafting  systems  which  only  produced  2-D  drawings.  The 
more  advanced  CADD  systems  now  work  with  3-D  models  of  building  projects,  from 
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which  2-D  drawings  can  be  extracted.  A 2-D  system  will  never  be  able  to  accurately 
receive  or  manipulate  a 3-D  model.  A 3-D  system  can  receive  a 2-D  drawing  and  ex- 
tend it  into  the  third  dimension  by  adding  a "z"  coordinate,  but  that  extension  will  only 
create  a subset  of  any  complex  3-D  model. 

Other  types  of  structural  differences  between  CADD  systems  are  their  use  of  attached 
databases  and  the  structure  of  the  data  components.  Each  CADD  system  employs  a 
different  database  management  strategy  for  managing  the  non-geometric  data  (product 
specifications,  responsibility  assignments,  procurement  dates,  etc.)  that  are  attached  to 
the  geometry.  All  of  these  factors  can  make  the  exchange  of  useful  CADD  data  be- 
tween different  systems  extremely  problematic.  When  these  problems  are  combined 
with  a lack  of  common  modeling  conventions,  it  is  extremely  difficult  to  exchange  use- 
ful information. 

The  use  of  CADD  modeling  concepts  must  be  clearly  specified  in  NAVE  AC  proce- 
dures so  as  to  ensure  complete  and  useful  CADD  data  exchanges.  The  use  of  levels  or 
layers  is  a key  operation  in  the  organization  and  control  of  CADD  information.  The 
number  of  levels  and  the  types  of  information  that  can  assigned  to  each  level  varies 
widely  between  CADD  systems.  In  the  similar  manner,  there  is  little  consistency  be- 
tween CADD  systems  as  to  the  use  of  the  terms  "model  space"  and  "model  size"  or 
"drawing  scale"  and  "plotting  scale". 

CADD  users  can  expect  a mismatch  of  CADD  systems’  capabilities  and  data  entities. 
A native  entity  may  have  no  direct  equivalent  in  another  CADD  system  or  multiple 
possible  representations  in  IGES.  In  such  instances,  the  original  data  will  be  translated 
into  less  sophisticated  data  elements,  and  the  translated  data  will  not  contain  the 
original  functionality.  This  can  result  in  inconsistent,  inaccurate,  or  inefficient  transla- 
tions. 


33  Key  Issues  Concerning  the  Transfer  of  Drawings  and  Project 
Definition  Data 

The  types  of  project  definition  data  that  may  be  exchanged  between  CADD  systems 
can  be  classified  into  the  following  categories: 

• geometric  (points,  lines,  surfaces,  etc.) 

• logical  relationship  (associativity,  connectivity,  bill  of  materials,  etc.) 

• graphic  display  (line  weights,  text  fonts,  drawing  definitions,  etc.),  and 

• non-geometric  (notes,  dimensions,  tolerances,  etc.). 
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Conventional  AEC  drawings  and  project  information  can  be  represented  by  combina- 
tions of  these  project  data  types.  Although  IGES  was  initially  developed  for  the  ex- 
change of  computer  graphics  and  digital  drawings  (geometric  and  graphic  display  data), 
the  specification  has  been  revised  to  accommodate  more  logical  relationship  and  non- 
geometric data. 

The  use  of  CADD  technology  and  digital  project  models  has  added  new  terms,  often 
with  multiple  meanings,  to  the  process  of  exchanging  AEC  project  information.  For 
the  implementation  of  IGES  and  the  control  documentation  on  IGES  files,  the  follow- 
ing terminology  should  be  used  [3]: 


• Associativity  is  a logical  link  or  relationship  between  different  entities.  This 
allows  entities  to  be  grouped  together  and  manipulated  as  one. 

• Attribute  is  information,  provided  in  specific  fields  within  the  directory  entry 
of  an  entity,  which  serves  to  qualify  the  entity  definition. 

• Connectivity  defines  the  physical  connections  between  components  and  sys- 
tems. 

• Drawing  Entity  is  a structure  entity  which  defines  a collection  of  views  of  the 
project  model,  with  any  required  annotations. 

• Level  is  an  entity  attribute  which  defines  a graphic  display  level  to  be  as- 
sociated with  the  entity. 

• Model  is  a single  definition  of  a project  (usually  in  3-D),  from  which  multiple 
projections  can  be  generated  for  different  views  and  drawings.  Model  Space 
is  the  right-handed  3-D  Cartesian  coordinate  space  in  which  the  project 
model  is  represented. 

• Property  Entity  is  a structure  entity  which  allows  numeric  or  text  information 
to  be  related  to  other  entities. 

• Subfigure  is  a structure  entity  which  permits  a single  definition  of  a detail  or 
symbol  to  be  utilized  in  multiple  instances. 

• View  defines  a 2-D  projection  of  a selected  subset  of  a model. 


At  present,  AEC  firms  have  had  only  marginal  success  with  the  exchange  of  drawing 
information  via  IGES.  The  received  data  sets  are  usually  used  as  reference  outlines 
for  new  work  and  are  not  intended  for  revision.  Some  common  problems  are: 

• problems  with  units  of  resolution,  scale,  and  positional  units;  e.g.,  match  lines 
do  not  match-up  on  segmented  drawings. 
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• entity,  symbol,  and  subfigure  mismatches;  e.g.,  parts  of  drawings  are  missing, 
title  blocks,  text,  and  dimensions  are  incorrectly  positioned  and  are  no  longer 
associated  (logically  linked)  with  the  other  data  elements. 

• crosshatching,  certain  line  styles,  and  most  line  font  patterns  are  not  success- 
fully translated;  so  A/E’s  avoid  putting  section  details  or  material  information 
into  their  IGES  files. 


In  most  cases,  translated  digital  drawings  have  to  be  edited  in  order  to  make  them 
"visually  equivalent"  on  the  receiving  system.  As  of  yet,  there  are  very  few  methods  for 
monitoring  the  quality  of  digital  drawing  exchanges  and  for  ensuring  that  the  data  sets 
were  translated  correctly. 

Data  set  validation  procedures  should  ensure  numerical  accuracy  and  the  usability  of 
the  translated  data.  The  method  used  by  most  AECs  is  to  do  a visual  comparison  be- 
tween the  received  "digital  drawings"  and  the  original  hard  copy  drawings.  This  is  usual- 
ly accomplished  by  plotting  the  translated  data  sets  and  overlaying  the  plot  on  top  of 
the  original. 

Even  if  a visual  inspection  is  successful,  this  does  not  ensure  that  the  translated  data 
sets  are  "functionally  equivalent"  on  the  receiving  system.  One  example  of  the  poten- 
tial for  functional  degradation  is  when  subfigures  are  translated  into  separate  vectors 
such  that  the  subfigures  can  no  longer  be  manipulated  as  single  entities  on  the  receiv- 
ing systems.  Any  comprehensive  measure  of  successful  data  set  translation  must  in- 
clude methods  to  assess  the  degree  to  which  the  received  data  sets  can  be  manipulated 
in  an  effective  manner  on  the  receiving  system. 


33.1  Symbols,  Details,  and  Libraries 

As  has  been  stated  earlier  in  this  report,  the  use  of  symbols  and  details,  or  "subfigures" 
in  IGES  terminology,  is  a primary  characteristic  of  AEC  drawings.  In  some  CADD  sys- 
tems, symbols  can  be  parameterized,  and  in  other  systems,  symbols  and  details  are 
stored  by  reference  to  a "master  library".  Since  these  libraries  are  periodically  updated, 
all  digital  drawings  in  IGES  form  must  contain  the  corresponding,  time-stamped  ver- 
sion of  any  pertinent  libraries. 

IGES  Version  3.0  does  provide  a MACRO  capability  to  represent  parameterized  IGES 
constructs  (such  as  user  defined  symbols)  and  the  External  Reference  File  capability 
for  referencing  libraries.  The  vendors’  implementations  of  these  enhancements  must 
be  fully  tested  and  validated  before  they  can  be  adopted  into  NAVF AC’s  standard 
IGES  operations. 
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3.3.2  Annotation 


All  CAJDD  systems  provide  for  some  types  of  annotations  and  dimensions  to  be  added 
to  drawings.  Some  CADD  systems  provide  comprehensive  annotation  capabilities, 
which  include  cross-hatch,  general  labels,  and  multiple  line  and  text  fonts.  Many 
CADD  systems  do  not  provide  such  broad  capabilities,  and  the  interchange  of  complex 
annotations,  via  IGES,  is  still  a highly  problematic  and  tedious  operation. 

The  representation  of  the  notes  on  a drawing  may  contain  such  variables  as  text  size, 
style,  line  spacing,  aspect  ratio,  character  sets,  text  box  size,  leaders,  and  witness  lines. 
These  will  usually  vary  between  systems,  and  IGES  Version  3.0  can  not  accommodate 
all  of  these  variables.  Text  and  dimensions  are  critical  components  to  the  under- 
standing of  drawings,  and  NAVFAC  will  have  to  establish  procedures  to  resolve  these 
limitations. 


3.3.3  Additional  Project  Definition  Data 

Although  IGES  3.0  can  be  successful  for  exchanging  drawings  and  some  annotation 
data,  the  current  implementations  of  Version  3.0  are  insufficient  for  exchanging  other 
kinds  of  project  definition  data,  such  as  property  or  attribute  information,  connectivity, 
bill  of  materials,  and  other  forms  of  tabular  data. 

Most  CADD  systems  allow  the  attachment  of  non-geometric  information  to  elements 
in  a drawing  or  model  (i.e.,  part  number,  weight,  or  maintenance  schedule).  Tabular 
data,  such  as  an  equipment  schedule  or  bill  of  materials,  play  a key  role  in  document- 
ing and  conveying  project  information.  These  tables  may  be  generated  by  using  key 
properties  that  are  attached  to  geometric  entities,  or  they  may  be  built  as  separate 
graphics,  with  no  relationship  to  a drawing  or  model. 

The  representation  of  connectivity  is  essential  to  many  phases  of  AEC  projects.  CADD 
systems  that  use  connection  data  will  often  produce  reports  on  physical  connections, 
logical  connections,  and  "from-to"  lists.  Although  IGES  3.0  can  include  this  informa- 
tion, the  current  translators  do  not  translate  the  connection  data  in  a consistent  man- 
ner. 

Each  of  these  situations  will  have  to  be  resolved  in  NAVF AC’s  specifications  for  digi- 
tal deliverables  and  IGES  translation  procedures.  If  IGES  is  to  succeed  as  a com- 
prehensive exchange  and  archival  format  for  NAVFAC,  these  additional  non- 
geometric data  types  must  be  supported  in  a uniform  manner  by  all  pertinent  IGES 
translators. 
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4.  Recommendations  for  NAVFAC’s  Implementation  of  IGES 

In  order  to  successfully  implement  IGES  for  the  digital  exchange  of  AEC  project  draw- 
ings and  project  definition  data,  NAVE  AC  should  allocate  resources  for  the  recom- 
mendations of  this  report.  These  recommendations  are  designed  to  address  both  the 
short-term  and  the  long-term  project  data  exchange  requirements  of  NAVFAC. 

The  objectives  of  these  recommendations  are: 

• to  establish  digital  and  auditable  drawing  exchange  capabilities; 

• to  move  beyond  the  transfer  of  only  the  graphics  of  drawings,  in  order  to  ac- 
complish more  functional  CADD  data  exchanges,  and 

• to  enhance  the  quality  and  usefulness  of  NAVE  AC’s  IGES  resources. 

The  project  databases  that  are  created  with  and  for  NAVE  AC’s  CADD  systems  will 
have  enormous  value.  A successful  strategy  for  integrating  CADD  within  NAVE  AC’s 
operations  must  permit  the  migration  of  these  databases  from  today’s  CADD  systems 
to  the  next  generation  of  systems  that  will  replace  them.  NAVE  AC’s  implementation 
of  IGES  must  be  part  of  a long-term  strategic  plan  for  digital  deliverables  and  techni- 
cal information  management. 


4.1  Establish  Short-  and  Long-term  Strategies  for  Digital  Deliverables 

The  effective  use  of  IGES  will  require  a comprehensive  view  of  the  information  flow 
of  NAVE  AC’s  AEC  operations  and  the  development  of  a systematic  IGES  implemen- 
tation plan.  This  should  include  documenting  what  information  is  needed  for  each 
NAVFAC  task  and  developing  a specification  and  timetable  for  how  that  information, 
in  various  forms,  will  be  delivered,  managed,  and  archived. 

Initially,  NAVFAC  should  implement  IGES  as  part  of  the  required  deliverables  for 
selected  lead  projects.  Since  the  current  generation  of  IGES  translators  (based  on  Ver- 
sion 3.0),  can  only  support  the  simple  graphics  of  project  drawings,  this  is  the  level  of 
capabilities  to  be  required  in  Phase  I of  implementing  IGES. 

NAVE  AC’s  specifications  for  project  deliverables  and  digital  data  transfers  must  define 
the  format  and  the  mechanisms  for  coordinating  the  use  of  the  various  types  of  required 
technical  information.  These  specifications  will  identify  the  responsibilities  of  NAV- 
FAC and  of  the  AEC  contractors  in  the  use  and  maintenance  of  the  digital  project  data. 
As  the  capabilities  and  reliability  of  the  IGES  translators  improve,  more  of  the  project 
information  can  be  required  in  IGES  format. 
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Central  to  the  long-term  plan  will  be  the  development  of  a NAVFAC  AEC  project  in- 
formation model.  The  project  information  model  will  be  used  to  specify  the  CADD 
data  modeling  conventions  and  the  data  translation  conventions.  With  a documented 
NAVFAC  AEC  project  information  model  as  a road-map,  appropriate  structuring  or 
mapping  to  future  CADD  systems’  data  structures  and  future  data  exchange  standards 
will  require  significantly  shorter  completion  schedules. 

IGES  does  have  limitations,  and  the  implementation  of  IGES  requires  careful  plan- 
ning, standardized  modeling  conventions,  comprehensive  translator  testing,  and  an  on- 
going data  translation  quality  assurance  program. 


4.1.1  NAVFAC  CADD  Objectives  and  Transition  Policies 

It  is  important  to  clearly  document  the  objectives  of  NAVFAC’s  move  to  CADD-based 
operations  and  the  policies  that  will  control  the  organization’s  transition  to  these  new 
ways  of  conducting  business.  Senior  management  must  demonstrate  a strong  commit- 
ment to  achieving  effective  and  efficient  digital  data  exchange  capabilities.  Without 
this  kind  of  leadership,  the  demands  for  expedience  in  construction  projects  may  cause 
some  of  the  long-term  goals  and  policies  to  be  short-circuited. 

A team  of  representatives  from  the  key  functional  units  should  be  organized  as  a task 
force  to  develop  NAVFAC’s  IGES  specifications  and  to  establish  a cost-effective  tran- 
sition program.  These  specifications  must  include  standard  conformance  tests  for  the 
procurement  of  IGES  translators  and  IGES  benchmark  test  cases  for  project  quality 
assurance  procedures.  The  establishment  of  this  task  force  is  a high  priority  item  and 
should  receive  immediate  resource  commitments  by  top  management. 


4.1.2  The  Use  of  Standardized  Modeling  Conventions,  Component 
Libraries,  and  Data  Translation  Procedures 

NAVFAC  must  establish  comprehensive  standards  for  CADD  data  exchanges  proce- 
dures. The  Department  of  the  Navy  and  NA  VFAC  have  already  established  standards 
for  engineering  drawings,  symbols,  and  CADD  databases.  NAVFAC  has  also  initiated 
a program  to  address  part  of  its  digital  data  transfer  requirements.  In  cooperation  with 
The  Construction  Specifications  Institute  (CSI),  NAVFAC  distributes  project 
specifications  in  ASCII  form.  These  specifications  must  be  expanded  to  include  the 
procedures  for  controlling  the  use,  exchange,  and  maintenance  of  digital  project  data, 
both  in  native  format  and  in  IGES  format. 

The  basic  IGES  implementation  strategy  is  to  develop  policies  and  procedures  to  en- 
sure that  the  required  project  information  is  exchanged  by  using  standardized  IGES 
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data  structures.  These  will  require  user  restrictions  on  the  originating  system  and  an 
evolutionary  approach  to  acquiring  and  maintaining  IGES  files. 

Central  to  controlling  NAVFAC’s  evolving  standards  for  CADD  operations  is  the 
development  of  the  NAVFAC  AEC  project  information  model.  This  model  provides 
a consistent  foundation/reference  for  specifying  and  managing  how  each  type  of  infor- 
mation will  be  exchanged  and  archived. 

In  order  to  chart  and  maintain  control  of  NAVFAC’s  long-term  migration  to  CADD- 
based  operations,  this  information  model  will  be  required.  During  the  short-term, 
NAVFAC  should  develop  specifications  for  IGES  deliverables  and  a schedule  for 
phases  of  development,  testing,  implementation,  and  revision  of  these  specifications. 


4.2  Establish  Policies  and  Procedures  for  the  Delivery  and 
Maintenance  of  Project  Information 

NAVFAC  must  establish  policies  and  procedures  for  coordinating  the  use  and  control 
of  conventional  hard  copy  with  both  IGES  deliverables  and  the  in-house  CADD 
databases.  IGES,  Version  3.0  or  4.0,  is  only  a partial  solution  to  NAVFAC’s  data  ex- 
change requirements.  The  current  version  should  initially  be  used  solely  for  transfer- 
ring the  geometric  and  graphic  information  of  conventional  drawings. 

NAVFAC’s  short  and  mid-term  project  information  requirements  will  include: 


• NAVFAC’s  native  CADD  representations  of  the  project  (currently 
CADDS®  4X  files  and  databases).  These  will  include  drawings,  the  3-D 
project  model,  and  any  additional  project  databases. 

• IGES  representations  of  the  project.  Initially,  these  will  be  2-D  drawings  with 
annotations.  These  may  well  include  redundant  data.  As  the  proven 
capabilities  of  IGES  translators  expand,  the  IGES  files  will  include  more 
functional  data  and  eventually  the  representation  of  the  3-D  project  model. 
These  requirements  will  be  updated  as  new  versions  of  IGES  are  released. 

• ASCII  text  files  for  the  additional  project  information  which  can  not  be  logi- 
cally linked  (associated)  with  the  IGES  files  and/or  the  native  CADD  files. 
These  may  include  drawing  schedules,  bills  of  materials,  project  management 
data,  purchase  orders,  and  maintenance  schedules. 

• Conventional,  hard  copy  construction  drawings,  as-built  revisions,  and  ar- 
chival drawings  (usually  stored  on  microfilm). 
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NAVFAC’s  procedures  must  efficiently  manage  and  control  project  digital  drawings, 
in  at  least  two  different  formats,  in  concert  with  the  other  types  of  required  project  in- 
formation. 

These  procedures  must  incorporate  the  transfer  of  standard  component  libraries,  sym- 
bol libraries,  engineering  change  orders,  as-built  revisions,  construction  drawings,  and 
any  other  types  of  required  hard  copy  documentation.  The  assignment  of  sole/prime 
authority  for  project  information  must  be  clearly  documented  and  monitored.  Only  by 
maintaining  a single,  authoritative  definition  (representation)  of  every  element  of  a 
project  can  NAVFAC  be  assured  of  data  consistency. 


4.2.1  Phases  of  IGES  Implementation 

NAVFAC  should  implement  IGES  in  phases,  building  from  basic  2-D  graphics  to  com- 
plete 3-D  project  models.  Key  lead  projects  will  be  selected  to  test  and  refine  each 
level  of  application  subset  and  digital  data  exchange  requirements.  Once  NAVFAC 
has  established  the  basic  digital  drawing  exchange  capabilities,  the  NAVFAC/IGES 
task  force  can  begin  testing  and  refining  the  next  level  of  capabilities. 

Phase  I / 2-D  drawings,  with  simple  graphic  annotations  (text  and  dimensions)  and 
visual  equivalence  to  conventional  drawings;  Level  I application  subset  requirements; 
no  non-standard  line  fonts,  multiple  text  fonts,  splines,  or  parametric  surfaces. 

Phase  II  / 2-D  drawings,  with  functional  annotations  and  associativities;  bill  of  materials, 
tabular  data  and  external  file  reference;  Level  II  application  subset  requirements. 

Phase  III  / 2-D  and  3-D  drawings,  using  the  model/view/drawing  concept  and  project 
models,  with  all  of  the  above  information;  Level  III  application  subset  requirements. 


4.2.2  Control  and  Archiving  of  Duplicate  Information 

A key  CADD  and  IGES  implementation  issue  is  assignment  of  prime  authority  to 
project  documentation.  This  becomes  particularly  important  when  there  is  a discrepan- 
cy between  the  hard  copy  documentation  and  the  CADD  (or  IGES)  files.  During  the 
short-term  NAVFAC  should  identify  the  original  CADD  database  or  the  appropriate 
engineering  drawing  as  the  sole  authority  for  dimensionally  stable  representations. 
Once  NAVFAC  has  advanced  to  Level  II  requirements,  the  issue  of  prime  authority 
should  be  reexamined  in  light  of  NAVFAC’s  long-term  digital  data  requirements. 

Another  important  issue  is  the  requirement  for  archiving  the  design  documents,  the 
CADD  digital  files,  and  the  audit  trails  of  design  responsibility.  The  assignment  of 
responsibility  for  A/E  design  decisions  usually  includes  a professional  stamp  with  a 
dated  signature.  The  signed  design  document  has  traditionally  become  the  legal  record 
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for  all  potential  liability  concerns.  With  the  increasing  use  of  CADD  data  sets  as  the 
primary  repository  of  design  decisions,  NAVFAC’s  archival  procedures  must  be 
revaluated  so  as  to  digitally  include  the  required  audit  trails  of  responsible  individuals 
and  any  other  information  necessary  for  legal  considerations. 

Data  exchange  requirements  become  even  more  burdensome  when  they  must  accom- 
modate the  archiving  of  data  for  later  use  and  the  updating  of  CADD  software.  Often 
data  generated  on  an  early  version  of  a vendor’s  CADD  software  will  not  be  complete- 
ly usable  on  a later  version.  These  data  exchange  problems  must  be  anticipated  be- 
cause future  use  of  data  may  be  on  a different  system. 


43  Develop  NAVFAC’s  Specifications  for  IGES  Translators  and  IGES 
Deliverables 

A critical  component  for  the  implementation  of  IGES  is  the  development  of  the  NAV- 
FAC/IGES  Translator  Specifications.  The  current  version  of  IGES  is  not  implemented 
uniformly  in  all  vendor-provided  translators,  and  most  IGES  translators  use  different 
subsets  of  the  specification. 

The  only  way  for  NAVF AC  to  ensure  some  level  of  data  exchange  capability  is  to 
develop  specifications  for  IGES  translators  and  for  the  delivery  of  IGES  files.  These 
specifications  will  be  used  as  part  of  NAVFAC’s  CADD  purchase  requirements  and  as 
a non-negotiable  item  for  new  construction  projects.  They  must  provide  sufficiently 
precise  definitions  of  the  subsets  and  of  the  standardized  IGES  encoding  procedures 
to  be  a legally  binding  document. 

The  specification  for  translators  must  clearly  state  which  IGES  entities  and  native 
database  entities  must  be  supported.  Initially,  this  will  require  identifying  the  graphic 
entities  used  in  the  drawings  for  a typical  AEC  project  and  writing  the  guidelines  for 
NAVFAC’s  required  use  of  those  entities  in  IGES.  These  guidelines,  with  the  relevant 
IGES  test  sets,  will  then  be  distributed  to  potential  AEC  contractors  for  validation, 
contract  qualification,  and  baseline  quality  assurance  procedures. 

The  development  and  refinement  of  these  specifications  and  test  sets  will  require  con- 
siderable effort.  This  will  include  developing  an  implementation  timetable,  the  criteria 
for  selecting  a project’s  required  level  of  IGES  deliverables,  and  comprehensive 
documentation  for  all  participants. 


25 


4.3.1  IGES  Application  Protocols  and  Application  Subsets 


A key  mechanism  for  controlling  the  flexibility  of  IGES  and  achieving  reliable  data  ex- 
changes is  the  development  and  use  of  application  protocols.  An  IGES  application 
protocol  is  the  formal  method  for  specifying  how  application  information  is  to  be  en- 
coded into  IGES  files. 

The  primary  components  of  an  application  protocol  are  a conceptual  information 
model  (which  describes  the  information  requirements  of  the  application  domain;  i.e., 
the  NAVE  AC  AEC  project  information  model),  an  application  subset  and  format 
specification,  an  application  protocol  usage  guide,  and  a set  supporting  test  cases.  An 
application  subset  is  an  unambiguous  subset  of  IGES  entities  which  span  the  data  re- 
quirements for  that  application. 

It  is  important  that  each  item  of  application  information  be  mapped  into  a unique  set 
of  IGES  entities,  versus  the  multiple  different  representations  that  are  possible  with 
the  unrestricted  use  of  IGES.  An  application  protocol  dictates  how  each  construct  of 
application  information  will  be  translated  into  IGES  entities. 

The  Department  of  Defense  CALS  (Computer-Aided  Acquisition  and  Logistic  Sup- 
port) Program  is  currently  reviewing  the  use  of  application  protocols/subsets  of  IGES 
as  part  of  the  Automated  Interchange  of  Technical  Information.  The  NAVFAC/IGES 
task  force  should  work  with  this  program  in  the  development  the  DoD/AEC  applica- 
tion subsets  and  application  protocols.  With  commonly  defined  application  protocols 
throughout  DoD,  the  CADD  vendors  will  be  far  more  likely  to  provide  uniform  and 
compatible  IGES  translators. 

The  documentation  for  NAVF AC’s  application  protocols  must  include  the  following: 

• Application  Area  Description  - A description  of  the  types  of  projects,  ap- 
plications, and  professional  disciplines  for  which  the  protocol  is  defined. 

• Application  Information  Model  - A documented  representation  of  the  in- 
formation requirements  of  the  specified  application  area. 

• Application  Subset  List  - The  description  of  each  IGES  entity,  its  pertinent 
forms,  and  directory  and  parameter  data  requirements. 

• Data  Accuracy  and  Functionality  Requirements  - The  required  accuracy  and 
functionality  of  the  exchanged  data.  This  may  include  retention  of  subfigures, 
connectivity,  and  various  types  of  associativity. 

• Information  Requirements  Mappings  - This  describes  how  each  type  of  ap- 
plication information  or  function  is  mapped  into  IGES  entities. 
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• Standardized  Conventions  and  Procedures  - Required  procedures  for  en- 
coding IGES  files. 

• Testing  and  Validation  Requirements  - The  test  procedures  and  test  cases 
used  to  ensure  complete  and  accurate  data  translations  with  the  application 
protocol. 

NAVFAC’s  initial  application  protocol  will  be  designed  to  only  support  2-D  drawings 
with  annotations  (text  and  dimensions).  In  order  to  define  this  first  application  protocol 
the  NAVFAC/IGES  task  force  should: 


• select  a sampling  of  the  key  types  of  projects  and  drawings  that  represent  the 
organization’s  responsibilities; 

• identify  the  different  types  of  information  in  the  drawings; 

• determine  the  optimum  mapping  into  IGES  for  each  type  of  information,  and 

• develop  test  scripts  and  files  for  each  element  of  information  and  each  func- 
tional component. 


Once  NAVFAC  is  successful  with  the  initial  (Level  I)  application  protocol  and 
guidelines,  these  can  be  expanded  to  2-D  drawings  with  associativity,  connectivity,  and 
bill  of  materials  (Level  II).  The  complete  NAVE  AC  application  protocol  (Level  III) 
will  support  all  of  the  above  information,  plus  drawings  using  the  model/view/drawing 
concept. 


4.3.2  Translator  Requirements 

The  current  generation  of  IGES  translators  is  insufficient  for  NAVFAC’s  digital  data 
exchange  requirements.  Since  there  is  no  public  certification  or  validation  program  for 
IGES  translators,  NAVFAC  must  independently  assure  the  capabilities  of  these 
software  tools  to  accurately  accomplish  the  data  translation  task. 

This  will  require  developing  NAVFAC’s  IGES  translator  specification  and  establishing 
access  to  a translator  validation  program.  The  validation  program  would  be  used  to 
identify  problems  in  current  translators,  to  propose  recommended  practices,  and  to 
help  ensure  the  delivery  of  quality  data  translation  software. 

NAVFAC’s  IGES  translator  requirements  should  be  based  upon  its  application 
protocols  (Level  I,  II,  or  III)  and  should  define  the  required  processor  capabilities.  The 
specification  for  translators  should  clearly  state  how  the  selected  IGES  entities  and  na- 
tive database  entities  must  be  supported. 
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The  documentation  on  many  translators  is  still  limited.  At  best,  the  documentation 
shows  how  to  mn  the  translator,  but  not  how  to  analyze  the  translation  problems.  Very 
few  translators  provide  comprehensive  error  recovery  capabilities,  editing  utilities,  or 
diagnostic  transaction  reporting.  Each  of  these  issues  must  be  resolved  in  the 
functionality  and  reliability  requirements  for  NAVFAC  (and  DoD)  IGES  translators. 

The  CADD  vendors  are  making  their  translators  more  effective,  and  some  are  now 
providing  options  in  their  IGES  processors  so  as  to  accommodate  the  requirements  of 
the  receiving  or  the  originating  system.  It  is  critical  that  the  DoD  CALS  Program  and 
the  NAFVAC/IGES  task  force  develop  comprehensive  translator  specifications  and 
conformance  tests  to  encourage  and  guide  the  continued  refinement  of  these  software 
tools.  Only  after  the  proper  tools  are  available  to  NAVFAC  and  the  AEC  industry,  can 
NAVFAC  establish  comprehensive  digital  data  exchange  capabilities. 

Conformance  to  the  NAVFAC/IGES  specifications  will  eventually  become  a non-ne- 
gotiable  item  in  RFP’s  for  CADD  systems  and  for  new  construction  when  deemed  cost- 
effective.  NAVFAC’s  specifications  for  CADD  deliverables  should  include  the  criteria 
for  determining  the  form(s)  in  which  different  types  of  project  information  will  be  re- 
quired. For  some  projects  it  may  not  be  cost-effective  to  require  IGES  files,  and  the 
criteria  for  exceptions  must  be  included.  NAVFAC  should  also  establish  procedures 
for  monitoring  and  enforcing  compliance  to  these  specifications. 


4.4  Develop  a Program  for  Coordinating  Translation  QA  Procedures 
with  Translator  Testing  and  Validation 

The  lack  of  mature  testing  procedures  has  continued  to  slow  the  broad  implementa- 
tion of  IGES.  There  are  considerable  differences  in  the  capabilities  of  various  vendors’ 
IGES  translators,  and  there  is  limited  consistency  in  how  these  translators  map  their 
native  data  into  IGES. 

Although  the  IGES/PDES  Organization  is  in  the  process  of  establishing  a translator 
verification  program,  no  results  will  be  available  in  the  short-term.  Therefore,  it  is  es- 
sential that  NAVFAC  establish  a program  for  coordinating  translation  quality  as- 
surance (Q  A)  procedures  with  the  periodic  testing  and  validation  of  IGES  translators. 

The  quality  of  a data  exchange  is  dependent  upon  the  correctness  and  completeness  of 
the  translator  implementations.  Achieving  and  maintaining  quality  control  is  a major 
consideration  in  CADD  data  management. 

Comprehensive  data  translation  quality  assurance  programs,  with  the  appropriate 
evaluation  criteria  for  monitoring  the  accuracy  and  functionality  of  the  received  data, 
must  be  developed.  These  should  include  translation  start-up  testing  procedures  which 
will  be  used  prior  to  each  new  project  and  as  part  of  any  request  for  digital  deliverables. 
In  most  AEC  operations,  data  translation  procedures  have  not  been  formalized,  and 
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In  most  AEC  operations,  data  translation  procedures  have  not  been  formalized,  and 
NAVFAC  will  have  to  provide  to  the  AEC  contractors  guidelines  on  the  required 
quality  assurance  procedures  for  digital  data  exchanges. 


4.4.1  Translator  Testing  and  Validation 

In  conjunction  with  the  production  of  these  IGES  specifications,  NAVFAC  must  docu- 
ment its  IGES  test  procedures  and  develop  a standard  test  library  for  ensuring  that  any 
proposed  translators  will  conform  to  NAVFAC’s  specifications.  This  will  include 
developing  test  scripts  and  files  for  each  required  IGES  entity,  for  each  functional  com- 
ponent of  a required  IGES  file,  and  for  each  element  of  required  technical  informa- 
tion. The  initial  objective  will  be  to  establish  a baseline  of  data  exchange  capabilities. 

The  science  of  software  testing  and  software  quality  control  is  just  beginning  to  develop, 
and  there  is  limited  consensus  as  to  the  purposes  of  software  testing.  The  primary  ob- 
jectives of  software  testing  are  to  expose  flaws  (errors)  in  the  product  and  to  execute 
the  intended  functions  correctly.  Yet,  exhaustive  input  testing  is  virtually  impossible 
due  to  resource  requirements.  This  forces  an  organization  to  maximize  the  yield  on  its 
testing  investment.  Therefore,  careful  attention  must  be  paid  to  designing  the  logic  of 
NAVFAC’s  test  procedures  and  test  sets. 

The  testing  of  IGES  data  translations  requires  two  types  of  benchmarks.  The  first  type, 
and  the  most  common,  is  called  the  IGES  reference  file,  and  this  uses  a "valid"  IGES 
representation  of  the  subject  information  element  to  test  the  capabilities  of  the 
postprocessor  (from  the  IGES  format  to  a CADD  system’s  format).  The  second  type 
of  required  benchmark  is  called  the  reference  model  script  (or  reference  test  script). 
This  provides  the  instructions  for  creating  the  subject  information  element(s)  in  an 
originating  CADD  system.  The  output  of  that  process  is  used  to  test  the  preprocessor 
(from  a CADD  system’s  format  to  the  IGES  format).  (Detailed  documentation  on  test- 
ing methods  and  types  of  tests  is  available  from  the  Testing  Methodology  Committees 
of  the  IGES/PDES  Organization). 

To  date,  only  the  largest  organizations  have  started  to  build  their  IGES  test  libraries, 
and  almost  all  of  these  are  merely  IGES  reference  files.  In  other  words,  there  has  not 
been  any  comprehensive  testing  of  multiple  IGES  preprocessors. 

An  example  of  the  magnitude  of  this  task  is  that  NASA’s  Goddard  Space  Flight  Center 
initially  spent  six  months  to  develop  a 28  Entity  IGES  Test  File  (and  the  file  only  tested 
the  most  basic  of  IGES  capabilities).  In  the  first  cycle  of  testing,  no  CADD  system’s 
translators  processed  the  entire  file  correctly.  NASA’s  28  Entity  IGES  Test  File  is  cur- 
rently in  its  third  revision  (in  two  years).  [9] 

NAVFAC  should  establish  access  to  an  unbiased  IGES/ AEC  translator  validation 
program.  This  program  is  needed: 
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• to  help  develop  comprehensive  quality  conformance  test  procedures  and  test 
sets; 

• to  test  and  validate  translator  software  (e.g.,  to  check  whether  the  application 
protocols  are  properly  implemented); 

• to  identify  problems  in  current  implementations; 

• to  propose  improved  recommended  practices,  and 

• to  help  ensure  the  delivery  of  quality  data  translation  software. 


The  current  version  of  IGES  is  not  implemented  uniformly  in  all  vendor-provided 
translators  (partially  due  to  the  flexibility  and  ambiguity  of  the  specification).  Most 
IGES  translators  support  different  subsets  of  the  specification,  do  not  have  comprehen- 
sive error  recovery  capabilities,  do  not  provide  diagnostic  transaction  reporting,  and  do 
not  generate  any  translation  error  log  during  execution. 

Due  to  all  of  these  concerns,  NAVE  AC  must  develop  a program  for  coordinating  the 
refinement  of  the  data  translation  procedures  with  the  ongoing  testing  and  validation 
of  IGES  translators.  Only  with  this  combination  will  NAVF AC  have  the  necessary 
resources  to  successfully  advance  its  IGES  capabilities. 


4.4.2  Start-up  Testing  and  QA/QM  Procedures 

As  part  of  the  transition  to  digital-based  operations,  NAVE  AC  must  develop  a program 
for  the  quality  assurance  (QA)  and  quality  management  (QM)  of  digital  data  exchan- 
ges. All  quality  control  and  quality  improvement  programs  are  based  on  quantitative 
measures  of  the  "conformance  to  specifications"  or  "fitness  for  use". 

Two  critical  issues  confronting  any  user  of  IGES  translators  are: 


• quantitative  measures  for  determining  the  quality  and  performance  of  the 
translator  (or  combination  of  translators)  and 

• the  evaluation  criteria  and  quantitative  measures  for  determining  a success- 
ful data  exchange. 

These  measures  provide  feedback  to  those  responsible  for  implementing  the  trans- 
lators and  for  executing  the  data  exchanges.  For  NAVF  AC’s  AEC  digital  data  exchan- 
ges, conformance  to  well  documented  IGES  application  protocols  and  the  reliable  in- 
terchange of  baseline  test  cases  will  be  the  primary  evaluation  criteria. 
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NAVFAC  will  have  to  use  both  types  of  measures  for  each  level  of  IGES  implementa- 
tion. A program  must  be  established  to  use  these  measures  for  monitoring  the  quality 
of  both  NAVFAC’s  IGES  translations  and  of  the  contracted  IGES  deliverables. 

Quality  can  not  be  added  to  a system  or  process  upon  completion;  it  must  be  built  into 
the  process.  As  part  of  the  quality  management  tasks,  NAVE  AC  should  develop  a 
quality  assurance  plan  which  describes  how  the  quality  of  the  data  exchanges  will  be 
examined  and  measured.  This  document  must  identify  each  participant’s  responsibility 
and  provide  a yardstick  for  measuring  improvements. 


4.4.3  Evaluation  Criteria  and  Reporting 

Digital  data  validation  procedures  must  ensure  the  numerical  accuracy  and  the  usability 
of  the  translated  data.  The  fundamental  issue  is  to  determine  the  criteria  for  success- 
ful data  translations.  The  most  important  evidence  of  a successful  translation  is 
whether  the  transferred  data  can  be  used  effectively  by  the  receiver. 

The  results  of  validation  testing  should  be  evaluated  in  relation  to  the  preservation  of 
the  original  information  content  and  required  functionality.  Functionality  of  the 
received  data  is  defined  as  the  ability  to  edit,  move,  scale,  or  otherwise  manipulate 
postprocessed  data  elements  as  if  they  were  created  originally  on  the  receiving  system. 

The  evaluation  criteria  for  validation  testing  and  quality  assurance  should  include: 


• correctness  of  the  syntax  and  structure  of  the  IGES  file;  referencing  the  NAV- 
FAC/IGES  specifications; 

• geometric  accuracy  of  the  received  data  files;  compare  the  resulting  accuracy 
to  the  prescribed  precision  and  tolerances; 

• retention  of  attributes,  associativity,  and  functionality;  compare  the  received 
file  to  the  original  file  or  model  description;  modify  the  generated  file  with 
a prescribed  sequence  of  manipulations  and  compare  that  result  to  the  in- 
tended result; 

• completeness  of  the  received  data  files;  compare  the  received  file  to  the 
original  CADD  model,  the  standard  reference  model,  or  the  reference  IGES 
model,  and 

• legibility  of  the  received  graphic  image;  compare  the  received  image  to  an 
original  plot  or  image. 
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Examples  of  useful  measures  for  these  evaluations  are: 


• How  well  did  the  processor  retain  the  entities  with  the  "required 
functionality"?  What  percent  of  these  entities  were  retained?  What  percent 
were  retained  by  being  translated  into  different  IGES  constructs? 

• How  well  did  the  processor  retain  the  required  information  content,  but  used 
non-standard  IGES  entities?  What  percent  of  the  required  information  was 
received?  What  percent  was  received  with  the  required  functionality? 

• How  well  did  the  processor  retain  the  required  accuracy?  What  percent  of 
the  geometric  entities  were  translated  with  the  required  accuracy?  What  was 
the  range  of  inaccuracy? 

• The  accuracy  and  usefulness  of  the  error  messages  and  the  translation  log  files 
that  are  generated  by  the  processor. 


The  use  of  these  measures  is  usually  tied  to  specific  test  cases  and  classes  of  test  sets. 

For  each  level  of  IGES  implementation,  NAVFAC  must  document  the  relative  impor- 
tance of  functional  accuracy  versus  visual  equivalence  (or  pictorial  accuracy).  Within 
NAVFAC,  the  functionality  of  the  received  data  should  be  the  primary  criterion,  as 
long  as  visual  equivalence  is  not  compromised.  NAVFAC’s  measures  for  successful 
data  translations  must  include  methods  to  assess  the  degree  to  which  the  received  data 
sets  can  be  manipulated  in  an  effective  manner  on  the  receiving  system. 

Currently,  the  evaluation  method  used  by  most  AECs  is  to  do  a visual  comparison  be- 
tween the  received  "digital  drawings"  and  the  original  hard  copy  drawings.  This  is  usual- 
ly accomplished  by  plotting  the  translated  data  sets  and  overlaying  the  plot  on  top  of 
the  original.  Even  if  a visual  inspection  is  successful,  this  does  not  ensure  that  the  trans- 
lated data  sets  are  "functionally  equivalent"  on  the  receiving  system. 

In  order  to  refine  and  improve  the  NAVFAC/IGES  specifications  and  data  exchange 
procedures,  the  quality  management  program  should  also  include  a mechanism  for 
reporting  test  results,  limitations,  and  enhancements  back  to  the  NAVFAC/IGES  task 
force.  During  the  initial  utilization  of  the  specifications  for  lead  projects,  every  effort 
should  be  made  to  establish  a team  of  the  participating  professionals  that  will  analyze 
problems  and  propose  resolutions  and  improvements. 

The  first  stages  of  implementing  IGES  will  be  resource  intensive.  If  the  transition  to 
using  IGES  is  planned  as  part  of  a long-term  strategy  and  investment  in  computer-based 
operations,  these  efforts  can  provide  NAVFAC  with  effective  and  reliable  digital  data 
exchange  capabilities. 
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5.  Summary 


This  report  presented  the  steps  that  NAVFAC  should  undertake  for  the  implementa- 
tion of  IGES  for  digital  data  exchanges.  The  successful  use  of  IGES  will  require  a 
thorough  analysis  of  the  information  flow  of  the  organization  and  the  development  of 
a systematic  implementation  plan. 

NAVFAC  needs  to  invest  resources  to  ensure  that  comprehensive  data  exchange 
capabilities  will  be  available.  IGES  provides  the  best  opportunity  because  it  gives 
NAVFAC  the  largest  leverage  on  the  development  of  comprehensive  data  exchange 
tools.  Once  the  required  AEC  features  are  in  the  standard,  all  vendors  and  AEC  con- 
tractors have  equal  access  to  them. 

There  are  two  parallel  projects  which  must  be  undertaken  for  NAVFAC  to  resolve  its 
current  data  exchange  problems.  First,  NAVFAC  must  establish  policies  and  proce- 
dures for  the  delivery  and  management  of  digital  data  and  technical  information. 
Second,  NAVFAC  must  establish  access  to  an  unbiased  IGES/ AEC  translator  valida- 
tion program.  This  program  would  test  and  validate  translator  software  (e.g.,  check 
whether  the  identified  entities  are  properly  translated)  and  identify  problems  in  cur- 
rent implementations.  The  testing  and  validation  of  IGES  translators  are  critical  to 
NAVFAC’s  successful  integration  of  CADD  technology. 

The  quality  of  a data  exchange  is  dependent  upon  the  correctness  and  completeness  of 
the  translator  implementations.  By  documenting  NAVFAC’s  required  use  of  IGES 
and  by  using  an  IGES/AEC  translator  validation  program  to  ensure  the  delivery  of 
quality  translation  software  tools.  NAVFAC  will  be  able  to  fulfill  its  current  CADD 
data  exchange  requirements. 

A summary  of  the  key  recommendations  is  presented  on  the  next  two  pages. 
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SUMMARY  OF  RECOMMENDATIONS 


1.  Establish  short™  and  long-term  strategies  for  digital  deliverables.  These  should 
document: 

• NAVE  AC’s  CADD  objectives  and  transition  policies,  and 

• NAVFAC’s  use  of  standardized  modeling  conventions,  component  libraries, 
and  facilities  databases. 


2.  Establish  policies  and  procedures  for  the  delivery  and  maintenance  of  CADD 
databases.  These  should  include: 

• Information  Management  Plan:  documents  what  information  is  needed  for 
each  NAVE  AC  AEC  task  and  specifies  how  that  information,  in  various 
forms,  will  be  delivered,  managed,  and  archived. 

• Phases  of  IGES  Implementation:  building  from  basic  2-D  graphics  to  com- 
plete 3-D  project  models.  Key  lead  projects  will  be  selected  to  test  and  refine 
each  level. 

• Phase  I / 2-D  model-mode  drawings  (single  view);  simple  graphic  entities 
(subfigures,  text,  and  dimensions);  no  non-standard  line  fonts,  multiple  text 
fonts,  or  parametric  surfaces;  Level  I application  subset  requirements. 

• Phase  II  / 2-D  model-mode  drawings  (multiple  views),  with  dimensional  as- 
sociativities and  external  file  references;  Level  II  application  subset  require- 
ments. 

• Phase  III  / 2-D  and  3-D  model-mode  drawings  and  project  models,  with  bill 
of  materials  and  tabular  data;  Level  III  application  subset  requirements. 
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SUMMARY  OF  RECOMMENDATIONS 
(continued) 


3.  Develop  NAVFAC’s  specifications  for  IGES  translators  and  IGES  deliverables. 

These  should  be  based  on  well-defined  IGES  application  protocols. 

• NAVE  AC’s  initial  IGES  application  protocol  will  be  designed  to  only  sup- 
port 2-D  model-mode  drawings  with  annotations  (text  and  dimensions).  The 
steps  of  this  process  are: 

• Select  a sampling  of  the  key  types  of  projects  and  drawings  that  represent  the  ' 
organization’s  responsibilities. 

• Identify  the  different  types  of  information  in  the  drawings  that  will  need  to 
be  exchanged.  Document  the  required  data  structure  (organization)  and 
prioritize  these  requirements. 

• Determine  which  of  this  information  is  appropriate  to  transfer  and  archive 
using  IGES.  Document  the  optimum  mappings  into  IGES  format  data. 

• Develop  test  scripts  and  files  for  each  element  of  information  and  each  func- 
tional component. 

• Develop  a "technical  information  management  specification"  which  will 
define  NAVFAC’s  required  use  of  IGES  and  will  coordinate  the  use  of  digi- 
tal data  with  the  other  forms  of  required  information. 

• Document  the  IGES  translator  requirements  and  develop  benchmark  test 
cases  and  procedures  for  ensuring  compliance. 


4.  Develop  a program  for  coordinating  translation  quality  assurance  procedures  with 
translator  testing  and  validation.  This  should  include: 

• Evaluation  criteria  for  monitoring  the  accuracy  and  functionality  of  the 
received  data,  and 

• Translation  start-up  testing  procedures  to  be  used  prior  to  each  new  project 
and  as  part  of  any  request  for  digital  deliverables. 

• NAVFAC  will  have  to  provide  to  the  AEC  contractors  guidelines  on  the  re- 
quired quality  assurance  procedures  for  digital  data  exchanges. 
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